On Tue, May 23, 2017 at 12:21:35PM +0100, Ian Jackson wrote:
> Sean Whitton writes ("Re: infinite number of Debian workflows (Re: Moving
> away from (unsupportable) FusionForge on Alioth?)"):
> > A way to set the version during the build, as you suggest, would be
> > sufficient to cover this. It is hard to see how we could relieve the
> > user of the need to understand how to choose a version number for a .deb
> > for testing. An option to set the version in the build command line
> > would remove the need for Debian source package knowledge.
>
> It would be best if the user would just pass an option to say `pls
> pick version number' and some tool would make a reasonable stab at it.Ah, I see, that would indeed be nice. > > > * Pull request workflow for submitting changes. This should > > > eventually turn into a bug submission to the Debian BTS. This > > > sounds to me like it probabl needs to be a web service, but > > > perhaps some local client utility that looked enough like a web > > > page would do. > > > > We basically already have all the pieces: > > > > - git-request-pull(1) > > - reportbug(1) > > - git hosting on alioth / our shiny pagure git hosting (coming soon) > > > > dgit could ship a script that ties these together. (The reason I suggest > > using our own git hosting is so that the branch doesn't disappear -- one > > advantage of patches in the BTS is that they can't 404.) > > I'm not sure that a command-line tool is what our target audience for > this would be looking for. But contributions certainly welcome. Hmm, I hadn't thought that it was the text-only nature of the interface that is proving off-putting. I thought it was purely the workflow. What I described could be wrapped up in a webapp or a desktop GUI -- reportbug already has one. I think we would need to see how pagure pans out before writing any code for this, as it might work as some sort of plug-in. -- Sean Whitton
signature.asc
Description: PGP signature
