Re: Release rpkg-1.66 and fedpkg-1.44

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 13, 2023 at 10:53:41PM +0200, Otto Liljalaakso wrote:
> Miro Hrončok kirjoitti 9.3.2023 klo 13.17:
> > On 09. 03. 23 10:05, Otto Liljalaakso wrote:
> > > Miro Hrončok kirjoitti 8.3.2023 klo 17.29:
> > > > 
> > > > However, maybe it does not work as I expected?
> > > > 
> > > > [python-setuptools (bundles %)]$ fedpkg prep
> > > > Not downloading already downloaded setuptools-65.5.1.tar.gz
> > > > Could not execute prep: Could not find the release/dist from
> > > > branch name bundles
> > > > Please specify with --release
> > > 
> > > Right, it looks like you interpreted "outside of an established
> > > dist-git repository" to cover the case where you do have a Git
> > > repository, but are in a local branch with a custom name.
> > > Unfortunately, currently only the case where there is no Git
> > > repository at all is covered.
> > 
> > Mea culpa. I assumed that's the case because I don't use fedpkg outside
> > of git much.
> > 
> > > I presume that in your example you intend to eventually create a
> > > pull request. Fedpkg should have a great support for that as well,
> > > but a bit (just a bit) more work is needed to cover that case. I
> > > suppose that it would be enough to, instead of printing the error
> > > you saw, fall back to using the same default mechanism that is used
> > > for the no-Git case. I will take a look at some point — unless
> > > somebody beats me to it, of course.
> 
> I took a look at this, and making '--release rawhide' for unknown branches
> is very easy [1]. I did not create a pull request yet, because I am a bit
> unsure if this is a good idea. My assumption is still that the vast majority
> of unknown branches are created for Rawhide pull requests. But for the ones
> that are for some other purpose, the default behavior changes from asking to
> be explicit with --release, to doing the wrong thing.
> 
> There would be log output notifying about defaulting to 'rawhide', and the
> --release parameter could still be used to select the correct release. So
> maybe convenience for the majority case weighs more than some risk for the
> minority case?
> 
> [1]: https://pagure.io/fork/oturpe/fedpkg/c/712dc656c4b06dafb693e5048baef45a0d82e973

I think this is reasonable.

>  self.log.info("'%s' is not match any release branch. "

"does not match".

I'd make it just one line:
"'%s' does not match any release branch, using 'rawhide'."

Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux